1. Technical Field
The present disclosure relates generally to information processing systems and, more specifically, to boot processing for computer systems.
2. Background Art
Before a computer system can operate, it must have an operating system (OS) in its memory that allows the computer's resources to be reached and controlled by the other software, such as the various application programs. The computer hardware has a non-volatile, comparatively simple bootstrap program to perform a boot sequence and load the operating system from disk. Typically, the bootstrap program is invoked by a BIOS (basic input/output system) program.
While most of the hardware of a computer system is provided by the computer vendor, the BIOS is typically provided by third party vendors, so the computer vendor has limited knowledge of, and control over, the specific contents of these items. However, the computer vendor may become aware of microcode patches that should be loaded during the boot process.
Regarding microcode patches, a typical instruction in a CISC (complex instruction set computer) computer processor performs a series of operations, with microinstructions that define some of the more complex operations being encoded in a non-volatile storage area in the form of microcode. The microcode defines all or a portion of the executable instruction set for the processor, and may also define internal operations that are not implemented in software-accessible code. The microcode is typically placed in a read-only memory (ROM) within the processor at the time the processor is manufactured. However, microcode sometimes needs to be modified after the processor is manufactured, and even after the processor has been placed into operation. Microcode patches allow such modification by adding additional microinstructions or inserting new microinstructions in place of the original microinstructions.
The microcode patches can be delivered to the processor in various ways. One manner of delivering patches is that the processor may support a field-upgradeable mechanism for the microcode ROM store; this mechanism is referred to as the microcode update. The microcode patches supported by the microcode update allow for changes to the microcode ROM in the field, in order to address errata, etc.
Some third-party vendors do not wish to support the microcode update mechanism. This is because the microcode update mechanism allows patches to be loaded via an interface to the operating system after the computer system (including BIOS code) has otherwise been validated by the third-party vendor. The ability of a user or IT department to load patches utilizing the microcode update mechanism after the system has been validated and shipped by the third party vendor may cause stability, quality and validation issues against the platform state that was shipped from the third-party vendor's factory. That is, subsequent patches may obviate the validation of the system, causing quality issues for a previously validated system, thereby reflecting poorly on the third party vendor that validated the system. Accordingly, at least some third-party platform vendors would prefer to incorporate all patches into a BIOS that has been fully updated with all microcode patches, validate the system, and know that no future microcode patches can be loaded later by the operating system.